Date: Thu, 21 Jan 93 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #20
To: packet-radio


Packet-Radio Digest         Thu, 21 Jan 93       Volume 93 : Issue   20

Today's Topics:
                           BayComm Software
                    High Speed Backbones? (2 msgs)
                      High Speed Backbones in CT
                 How to learn about packet? (2 msgs)
                   KA9Q NOS - saving screen output
             PK-232 vs MFJ1278 (opinions wonted) (2 msgs)
             Ramsey IBM PC packet TNC any good? (2 msgs)
                              subscribe
                   TCP/ax25 for Sun sparc help????
                               Why not?
                 Working KA9Q (PPP/C-SLIP) for Unix?

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 20 Jan 1993 18:31:11 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!linac!tellab5!jwa@network.UCSD.EDU
Subject: BayComm Software
To: packet-radio@ucsd.edu

Can someone E-mail me a copy of the BayComm software.  I can't FTP
from this site.  I have uudecode and pkunzip capabilities.

I shure would appreciate it!  Thanks!




--- 
   Jack Albert               Fellow Radio Hacker
			     Tele (708) 512-7854
   Tellabs, Inc.             FAX  (708) 852-7346 
   4951 Indiana Ave.         jwa@tellabs.com
   Lisle, IL              
   60532                     Do things really go better with Coca-Cola?

------------------------------

Date: 20 Jan 93 15:28:35 GMT
From: news-mail-gateway@ucsd.edu
Subject: High Speed Backbones?
To: packet-radio@ucsd.edu

If most of the users in an area are 1200 bps, as is the case everywhere
in the world right now, then 9600 bps links are more than adequate
between nodes and services (services being BBSs, callsign databases,
tcp routers, etc).

When the 9600 bps users (users, as opposed to network infrastructure)
become a significant segment of the population, then the links between
nodes and services have to be higher speed to avoid congestion.  The
next logical step above 9600 bps is 56kb.

It is clear to me that simplex packet can only work in very small cells
where every user can hear every other user.  Unless you design a
network in that way, the collision-retry nature of the channel will
guarantee throughput in the slow snail category.

A full-duplex repeater solves that problem by completely eliminating
the hidden-terminal problem, and thus resolves a goodly amount of the
collision congestion.  It also avoids the incredible waste of bandwidth
that digipeaters and net/rom nodes represent.

One high-level repeater can serve a very large area.  However, in my
view, it is better to have small regions (perhaps a town or community)
served by a low-level repeater through which all local packet stations
would communicate, coupled with a network interface that connects to a
central multi-community high-level repeater used only for the regional
systems to communicate.

Making the community repeaters 1200 bps (and dual-speed with 9600 bps
as well) means that the users don't have to do much except learn how to
operate the offset switch on their radios.  Making the central hub
repeater operate at 9600 bps ensures that there is sufficient bandwidth
for inter-regional communications, and it resolves the difficulty of
making the 9600 bps stuff work by leaving it to the technical teams who
build the repeater.

Yes, it's a significant investment in network infrastructure.  Perhaps
more important is that it's a significant investment in cooperation,
which hams have never been real strong on.  But it will work WELL, far
better than the ham packet networks in place in 90% of the world now.

I think we ought to try it.  If I have the chance to re-engineer the
San Diego metro network, this is the way I'm going to go.

Sometimes you can't see how to do things right until you've tried other
methods.  But that's one of the biggest parts of ham radio: experimentation.
	- Brian

------------------------------

Date: Wed, 20 Jan 1993 17:18:20 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!usenet.ins.cwru.edu!gatech!emory!kd4nc!ke4zv!gary@network.UCSD.EDU
Subject: High Speed Backbones?
To: packet-radio@ucsd.edu

In article <93018.142422PJC130@psuvm.psu.edu> <PJC130@psuvm.psu.edu> writes:
>We are looking to install a backbone system around the SW Pa area.  What
>I've seen of the TexNet system is OK, but we would like to go > 9600 for the
>backbone.  (19200 is OK, 56K is preferred).
>
>One of the ideas that we have is that each point to point link is on its own
>channel (multiple transceivers), another is that there is only one
>transmitter per site, but multiple receivers.  In either case, we certainly
>need more than two ports per node.
>
>As ease of use (user transparency) is very important, a multiple NET/ROM or
>TheNet hookup is not acceptable.
>
>Any ideas?

Hubs with multiple receivers and a single transmitter can be useful
when dealing with a user base. This is a technique used by AMSAT
with the Pacsat birds. However, it makes network topologies and
frequency reuse plans really complicated. Dedicated, full duplex
backbone links are best, with a frequency reuse plan that alternates
channel pairs in a cellular layout. This means that a switch needs
at least 3 ports. One for neighbor left, one for neighbor right,
and one for the user LAN. A Kantronics Data Engine is suitable for
this kind of network tap. At a site where several trunks are hubbed,
however, you really need a PC with multiple dedicated DMA capable
cards, like the Gracillis cards. Running a switch optimized version
of KA9Q, these can handle 5 or more ports.

I wrote the mulport code in early versions of KA9Q to make the
system look simple to users. To them it looks like a flat digi
network all operating on the same channel. They use normal digi
strings and the system routes their packets, on a packet by packet
basis, to the proper port for forwarding. Thus they don't have to
know anything about frequency pairs or speed changes. All they
needed to know was a digi path list. Now that's mostly obsolete
thanks to the Netrom support in later versions of the code. The
user sees what looks like a normal Netrom network and again has
all the implementation details hidden from him. The user running
TCP/IP has it even better. He doesn't have to know anything but
the target host's name to use the network. Keeping the network
transparent to the user is very important if naive users are
to be supported. Hiding routing decisions in the switches means
that users don't have to depend on ad hoc routing tricks that
may change over time. As a switch maintainer, you can change
the way the network is configured at will while still keeping
it looking the same to a user.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary      
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: 20 Jan 93 16:20:19 GMT
From: news-mail-gateway@ucsd.edu
Subject: High Speed Backbones in CT
To: packet-radio@ucsd.edu

Could anyone out there give me as much info about the TCP/IP Network  
in the CT area??

-Nick KD1LR

nick@ccsi.com

------------------------------

Date: Wed, 20 Jan 1993 16:58:43 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!usenet.ins.cwru.edu!gatech!emory!kd4nc!ke4zv!gary@network.UCSD.EDU
Subject: How to learn about packet?
To: packet-radio@ucsd.edu

In article <8793@news.duke.edu> jbs@ee.egr.duke.edu writes:
>In article <14JAN93.16332787@nauvax.ucc.nau.edu> cvm@nauvax.ucc.nau.edu writes:
>>Can anyone recommend a good book or two (or other source of info) about packet. 
>>I would like a good introduction/overview and some more details and technical
>>information.  For example: I would like to know the details of the AX.25
>>protocol.
>
>I can name a book that you should *not* waste your money or time on.
>
>*DON'T BUY* "PRIME: Packet Radio is Made Easy" (published by MFJ).
>
>I picked up this piece of trash at a hamfest and am absolutely amazed that
>MFJ (or any company!) would want its name attached to such bad writing.
>It's obvious that no proofreader ever laid an eye on the text before it
>went to press.  Organization is poor; the author wanders aimlessly from one
>topic to another with little linkage between topics.  Information oscillates
>from fuzzily vague to MFJ-specifically detailed.  There is no indication on
>the cover or in the introduction that 80% of the information in the book is
>specific to MFJ TNCs and software (neither of which I possess); if you did
>buy MFJ equipment the book might be marginally more helpful to you.

This is a Buck Rogers book. Buck's the CQ packet editor, and his writing
is of CQ quality. :-) He writes the way he talks, in great volumes and
with little sense of grammar or spelling. 

Buck is highly opinionated, and his opinions change daily. :-)
The hookup information he gives is largely correct, but the
quaint ideas he has on networking and network services are best 
taken with a large grain of salt. This is especially true in older 
editions. He has progressed(?) from championing digis, to Netroms, 
to Rose, and finally he's now asking questions on how to setup TCP/IP.

He has enormous stores of enthusiasm, and he's a real doer.
Reading his book gives you insight into the typical amateur's
approach to packet. He championed the C64 long after it was
dead and is just now moving into commodity PCs. His model
of packet is as an interactive keyboard to keyboard service.
Don't use this book as a definitive text on networking, or
network services, but it is a valuable text for gathering
insight into the ways real amateurs are using packet radio
and to the obstacles developers of real networks face.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary      
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: Wed, 20 Jan 1993 20:03:06 GMT
From: sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscit.sc.hp.com!hplextra!hpfcso!hplvec!tcline@ames.arpa
Subject: How to learn about packet?
To: packet-radio@ucsd.edu

> In rec.radio.amateur.packet, tcline@hplvec.LVLD.HP.COM (Ted Cline) writes:
> > In rec.radio.amateur.packet, cvm@nauvax.ucc.nau.edu writes:
> > 
> > For example:  I would like to know the details of the AX.25 protocol.
> > 
> > --------------------------------------------------------------------------
> > Chris Michels -- Systems Programmer             cvm@nauvax.ucc.nau.edu
> > Northern Arizona University -- Flagstaff, AZ    cvm@nauvax.bitnet
> > Phone: (602) 523-6495                           N7YIU
> 
> 
> I have uploaded the "AX.25 Amateur Packet-Radio Link-Layer Protocol,
> Version 2.0 October 1984" specification as ax25.doc in /hamradio/packet/
> on ucsd.edu .  If you have problems getting the file, I'll be pleased to
> email it to you.
> 
> If you have Internet mail but not FTP, try the FTP mail server:  send a
> mail message with the subject "help" and a single message line "help" to
> ftpmail@decwrl.dec.com.
> ----
> Ted Cline, N0RQV


I also offer to email any combination of the following files:

  42024 bytes, Dec  8 13:06, FAQ_HAM9212  = rec.radio.amateur.misc FAQ
  14055 bytes, Jan  4 21:46, FAQ_PACKET   = rec.radio.amateur.packet FAQ
  11433 bytes, Aug 11 17:37, PACKET.TUT   = A "packet tutorial" (from 
					    PACKET.ARC)

----
Ted Cline, N0RQV                    VXI Systems Division
ted_cline@hpisla.lvld.hp.com        Hewlett-Packard, M/S CU-326
tcline@hpislx.lvld.hp.com           815 14th Street SW
VOICE: (303) 679-2352               P.O. Box 301
FAX:   (303) 679-5971               Loveland, CO  80537  USA

------------------------------

Date: 21 Jan 93 00:17:30 GMT
From: munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!thrip!turner@uunet.uu.net
Subject: KA9Q NOS - saving screen output
To: packet-radio@ucsd.edu

Does anyone know of a version of KA9Q NOS which will allow the
output to the PC screen (eg. hop check tracing, icmp status) to be 
redirected to a file?

I am helping to get NOS set up for teaching purposes and 
want to be able to print out the screen info.  I am 
currently running JNOS105.EXE which is KA9Q NOS version
911229, Johan Reinalda WG7J/PA3DIS on 2 XT's.  I have found the
trace command useful as it allows tracing to be stored
in a tracefile, but am wondering if any other commands
can do this or any other versions of NOS.

Thanks in advance for any help.


---
  Margaret Turner		email: turner@cs.uq.oz.au
  Computer Science Department	fax:   +61 7 365 1999
  University of Queensland
  Australia  4072
   

------------------------------

Date: 20 Jan 93 17:21:40 GMT
From: news-mail-gateway@ucsd.edu
Subject: PK-232 vs MFJ1278 (opinions wonted)
To: packet-radio@ucsd.edu

Hi all,

Some time ago I decided to by new all modes TNC. After short searching
it looks there are only to models to consider: PK-232 and MFJ-1278.
There is very hard to choose especialy that it will not cost a couple
of bucks... I am not very experienced on this field so I do rely on
opinions of other packet friends.
I tryed to compare PK and MFJ by myself but it seems to be difficult.
Here are some remarks:

Prices are easy to compare. Well, Pk-232 is about 70 $ more expensive then
MFJ-1278. Let's try to find reasons of it.

There are  of course a lot of PK's advantages which I think result from a long
presence of AEA on a market (14 years!). There is very good service support,
long list of distributors, well developed user friendly software (with some
exclusive commands). AEA also takes care of easy to operate front panel
design, all necessary cables and connectors are always included. And the most
important. There are over 50 000 PK in use around the world. It looks like a
standard...

We all apreciate these features but I think the most important are technical
differences.
As we all know good selectivity is what we need when chasing DX in poor
conditions.
Here are two descriptions. Which one is right, maybe both? If both which one
unit is better? Maybe I am trying to compare here an elephant and
a toothbrush???

AEA:
"... The PK-232 has no compromise VHF/HF/CW modem with eight pole Chebyshev
bandpass filter folowed by a limiter discriminator with automatic treshold
correction. (...) can be configured for optimum performance with different
types of signals. ..."
"... One multi-mode contoller offered by another (probably MFJ) uses no input
filtering on any mode. ..."
"... While another manufacturer does offer selectable modem setings for
different types of signals in their multi-mode controller, shortcuts in modem
design limit the filter's performance. ..."

And MFJ:
"... MFJ-1278 is the only multi-mode with a true DCD circuit. This dramatically
reduces sensitivity to noise and dramatically increases completed QSOs. ..."
"... Tests in Packet Radio Magazine prove the modem used in the MFJ-1278
copies HF packet more accurately than all other modems tested. ..."

Looks great but there could be only one THE BEST! Any opinions welcome!

PK offers exclusive Packet Lite and mailbox which can be accesed in AMTOR as
well as packet. But PK-232 does not offer SSTV. AEA asserts that this type
of modems is not able to provide satisfactory SSTV performance. They advise
to buy separate modem...
Is there anybody who can tell something about MFJ-1278's SSTV?

I know that high speed modems can be conected to PK-232 but what about MFJ?
Is there any way or possibility to connect PSK modem to one of these units?

There are a lot of PK-232 users but I want to consider opinions of MFJ-1278
defenders also. Any advise can help me to make up my mind...
Thank you in advance,

73 de Greg, SP1WSN

------------------------------

Date: Thu, 21 Jan 1993 03:42:31 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!cs.utexas.edu!hermes.chpc.utexas.edu!news.utdallas.edu!feenix.metronet.com!marcbg@network.UCSD.EDU
Subject: PK-232 vs MFJ1278 (opinions wonted)
To: packet-radio@ucsd.edu

In article <9301201751.AA22332@ucsd.edu> GREG@PLSZUS11.BITNET writes:
>Hi all,
>
>Some time ago I decided to by new all modes TNC. After short searching
>it looks there are only to models to consider: PK-232 and MFJ-1278.
>There is very hard to choose especialy that it will not cost a couple
>of bucks... I am not very experienced on this field so I do rely on
>opinions of other packet friends.

My money is on the PK232.  I've owned both, and the PK232 is far superior
on CW reception (not what you may use it for, but you never know).  Also,
AEA has a history of continually updating the firmware for the unit since
it came out.  Not the MFJ doesn't, but I've been less than impressed with
my dealing with the MFJ customer service department.  Also note that
Kantronics makes an all-mode (KAM) which you should also consider.  It's
smaller in size than the PK232.  I don't have experience with the KAM but
I am very impressed with my KPC4 dual port modem.  Good luck and happy
hunting, hope this helps.
___
Marc Grant, N5MEI
marcbg@feenix.metronet.com
call 146.88 when in Dallas, Texas!

------------------------------

Date: Wed, 20 Jan 1993 21:48:12 GMT
From: pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!allegra!rfc@network.UCSD.EDU
Subject: Ramsey IBM PC packet TNC any good?
To: packet-radio@ucsd.edu

At a hamfest last weekend I saw, at the Ramsey electronics table, a TNC
kit.  This TNC is designed to connect (and get its power from) the serial
port (think it was the serial port, it's been a few days ago!).  "No
adjustments, all feeqs are crystal referenced", "platform for 'poor man's
packet'".  price: $60.  connects to radios and HTs.

Anyone buy and build this thing?  Any good?  for the money?

------------------------------

Date: Thu, 21 Jan 1993 04:23:25 GMT
From: think.com!yale.edu!ira.uka.de!sol.ctr.columbia.edu!news.cs.columbia.edu!popovich@ames.arpa
Subject: Ramsey IBM PC packet TNC any good?
To: packet-radio@ucsd.edu

> At a hamfest last weekend I saw, at the Ramsey electronics table, a TNC
> kit.  This TNC is designed to connect (and get its power from) the serial
> port (think it was the serial port, it's been a few days ago!).  "No
> adjustments, all feeqs are crystal referenced", "platform for 'poor man's
> packet'".  price: $60.  connects to radios and HTs.

Not to sound like a Clueless Appliance Operator(TM), but why take the
trouble to assemble a kit when you can buy what sounds like the same
thing from Tigertronics for about the same (actually, a few $$$ LESS)?
	-Steve

------------------------------

Date: 20 Jan 93 20:46:10 GMT
From: news-mail-gateway@ucsd.edu
Subject: subscribe
To: packet-radio@ucsd.edu

subscribe 

------------------------------

Date: 20 Jan 93 17:49:41 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!linac!att!mcdchg!laidbak!newsserver.pixel.kodak.com!kodak!eastman!isctssl!braun@network.UCSD.EDU
Subject: TCP/ax25 for Sun sparc help????
To: packet-radio@ucsd.edu

Hi, we're trying to get ax25 running on a sparc station. we 
have a copy of the ax25 for the sun (written by a ve6) installed.
Pings to get transmitted. etherfind sees the packets coming 
and going. the packets look good going on the radio side both to
and from the station. the problem is that the interface to 
the window that we're working from (originating the ping) does
not get any responses. It seems as though the low level routines
see the packets, but they never make back to the sun window for
display. We're running 4.2 release. Thanks for any pointers, we
are a little stumped at the moment. We really need a working ax25
interface on our sun, and we'd really like to do IP after
that. So any help would be greatly appreciated. I have also 
sent this to the tcp mail group. 
-- 
Curtis Braun (curtis@computronics.com) (n2hkd)
Computronics, POBOX 1002 Fairport,NY 14450 
Guest@Digital Telstar,Network Operations Center Kodak 

------------------------------

Date: 20 Jan 93 14:11:15 GMT
From: swrinde!gatech!darwin.sura.net!paladin.american.edu!news.univie.ac.@!hp4at!mcsun!sunic!lunic!eru.mt.luth.se!enterpoop.mit.edu!hri.com!spool.mu.edu!sol.ctr.columbia.edu!destroyer!wsu-cs!
Subject: Why not?
To: packet-radio@ucsd.edu

Why doesn't someone get a one way feed going to this newsgroup and then
moderate it so that responses can go through a validated gateway?

swood

-- 
 All Month  Rabbit and Crow are legal to hunt all month in Michigan
  Current   Michigan Canada Goose special late season still open
      (Southern Michigan Game Management unit only w/stamp)
         <<<<<<  Only nine months until bow season!!! >>>>>>

------------------------------

Date: Wed, 20 Jan 1993 22:49:48 GMT
From: newsgate.watson.ibm.com!yktnews2.watson.ibm.com!yktnews!admin!aixproj!uri@uunet.uu.net
Subject: Working KA9Q (PPP/C-SLIP) for Unix?
To: packet-radio@ucsd.edu

Hello,
	I'm trying to find a working port of KA9Q to 
	Unix for a month now... I need it to support
	SLIP (hopefully with compression), PPP and
	AX25 (of course :-).

	I've seen "unixnet.cpio.Z" from ucsd.edu: it's nice,
	but extremely limited.  And it's dated 1989/1990...
	So I made sure it compiles fine,  and doesn't crash
	when invoked,  but since it doesn't support PPP and
	C-SLIP, it won;t help me greatly...

	"nosunix-all.tar.Z"  from <don't remember> seems to be
	a full-blown port, BUT... I can't get it running!  It
	barely compiles (after several fixes), and then I've 
	no way to debug it,  it simply crashes with memory 
	fault immediately after being invoked...  I'm not 
	very skilled with GDB, and it's too big for DBX.

	I'm trying to do this on AIX/PS2 v.1.3 and on ESIX 
	Rev.D (Unix SysV.3.2/386)...

	Any help is APPRECIATED!
-- 
Regards,
Uri.		uri@watson.ibm.com
------------
<Disclaimer>

------------------------------

Date: Wed, 20 Jan 1993 22:29:00 GMT
From: ucselx!sol.ctr.columbia.edu!howland.reston.ans.net!spool.mu.edu!uwm.edu!uucp.mr.med.ge.com!rdsunx.crd.ge.com!dssv01!kennykb@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <1j9hqcINN9rf@matt.ksu.ksu.edu>, <1993Jan16.201038.1158@sbcs.sunysb.edu>, <1993Jan18.003912.26961@qualcomm.com>
Reply-To : kennykb@crd.ge.com
Subject : Re: CDMA Packet Radio


In article <1993Jan18.003912.26961@qualcomm.com>, karn@servo.qualcomm.com (Phil
Karn) writes:
In article <1993Jan16.201038.1158@sbcs.sunysb.edu> rick@cs.sunysb.edu (Richard
Spanbauer) writes:
>	The main hitch with CDMA (code division multiple access) is that
>	the amateur radio service is allowed to use only three spreading
>	codes.  Is there work being done towards relaxing the regulations
>	on use of spreading codes?

One of those polynomials gives a spreading sequence that's 524287
chips long.  How well can we implement CDMA using different positions
in that spreading sequence?

73 de ke9tv/2, Kevin KENNY	GE Corporate R&D, Niskayuna, New York, USA

------------------------------

Date: 20 Jan 93 23:05:47 GMT
From: eram!dave@midway.uchicago.edu
To: packet-radio@ucsd.edu

References <1j9hqcINN9rf@matt.ksu.ksu.edu>, <1993Jan16.201038.1158@sbcs.sunysb.edu>, <1993Jan18.003912.26961@qualcomm.com>
Subject : Re: CDMA Packet Radio (WAS Re: Who do repeater coordinators represent?)

In article <1993Jan18.003912.26961@qualcomm.com>,
    karn@servo.qualcomm.com (Phil Karn) writes:

[ USA Amateurs can use only three spreading codes ]
| I'm sure if there was a real need to change the rules, the FCC would
| be willing to change them. There's an STA in existence right now
| that waives this requirement.

As an aside, there are no restrictions whatsoever on the use of SS
technology in Australia (except being "wide band" it must be > 420 MHz).

-- 
Dave Horsfall (VK2KFU)         VK2KFU @ VK2RWI.NSW.AUS.OC
dave@esi.COM.AU                ...munnari!esi.COM.AU!dave

------------------------------

Date: Wed, 20 Jan 1993 13:26:42 GMT
From: sdd.hp.com!ncr-sd!ncrcae!ncrhub2!ciss!law7!jra@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <93018.142422PJC130@psuvm.psu.edu>, <C13x9L.MCC@srgenprp.sr.hp.com>, <1jhq8tINNadc@network.ucsd.edu>
Subject : Re: High Speed Backbones?

brian@ucsd.edu (Brian Kantor) writes:

>Were I to do the San Diego Metro net over again, I'd put a single packet
>9600 bps repeater up on a central location, and have all the outlying nodes
>and services connect through it.

This is what we're in Dayton with the 19.2 repeater.  It provides the 
"backplane" for the other services to connect to.  Rather than upgrade 
speed (for right now) our plans are to add a second repeater when the 
load is high enough to justify it -- we'll put users on one repeater 
and servers on the other.

>Later, when there are more than two 9600 bps USER stations on the air in
>town, we'd upgrade the repeater to 56kb.

Given the way folks are not rushing to embrace a solution that's about 
as close to "plug and play" as it gets, I don't anticipate we'll need 
the second repeater for a couple of years...

>Simplex packet is so difficult to make work properly* that it's really
>not worth trying.

It's worth noting the the switch to a new baud rate/frequency/band is
the ideal -- and probably the only -- time to implement a network like
this and have some chance of getting it to work.  Once users have
settled into the simplex-"helped"-by-digi mode, inertia will make it
almost impossible to change to a network that works.

John

-- 
John R. Ackermann, Jr.         Law Department, NCR Corporation, Dayton, Ohio
(513) 445-2966		       John.Ackermann@daytonoh.ncr.com
Packet Radio: ag9v@n8acv.oh    tcp/ip: ag9v@ag9v.ampr [44.70.12.232]

------------------------------

End of Packet-Radio Digest V93 #20
******************************
